Meh, I've ever seen only 3-4 apps requiring .env file to be there and writable...

A solution is to edit the dockerfile on our mirror and create an empty .env file.

Configmap would be read-only.
Mounting the whole /app dir will probably cause problems later.

cant we just chown the log dir using an initscript and keep it on 568?

cant we just chown the log dir using an initscript and keep it on 568?

Probably not. if I remember right, the user running the process that writes on logs dir is www-data

Mounting the whole /app dir will probably cause problems later.

Yes, it's what caused #3006

A solution is to edit the dockerfile on our mirror and create an empty .env file.

The empty file is actually there, but only writable by root. I also tried setting PUID to 0 but the web process always runs as www-data user.

Probably not. if I remember right, the user running the process that writes on logs dir is www-data

The same goes for the backup dir.

The empty file is actually there, but only writable by root. I also tried setting PUID to 0 but the web process always runs as www-data user.

What happens if you run it with user 0, group 82 and fsgroup 82 ?

What happens if you run it with user 0, group 82 and fsgroup 82 ?

Like this?

Still getting the same error:

The stream or file "/app/storage/logs/laravel-2022-07-02.log" could not be opened in append mode: Failed to open stream: Permission denied

What happens if you run it with user 0, group 82 and fsgroup 82 ?

Like this?

Still getting the same error:

The stream or file "/app/storage/logs/laravel-2022-07-02.log" could not be opened in append mode: Failed to open stream: Permission denied

fsGroup to 82 also

fsGroup to 82 also

That works, too, just as my fix with (0, 0, 82). What are you hoping to achieve with this?

Here's the ps a output if that's helpful:

/app # ps a
PID   USER     TIME  COMMAND
    1 root      0:00 {supervisord} /usr/bin/python3 /usr/bin/supervisord -c /etc/supervisor.d/supervisord.ini
    7 root      0:00 php-fpm: master process (/usr/local/etc/php-fpm.conf)
    8 root      0:00 nginx: master process /usr/sbin/nginx -g daemon off;
    9 www-data  0:00 php-fpm: pool www
   10 www-data  0:00 php-fpm: pool www
   11 nginx     0:00 nginx: worker process
   12 nginx     0:00 nginx: worker process
   13 nginx     0:00 nginx: worker process
   14 nginx     0:00 nginx: worker process
   15 nginx     0:00 nginx: worker process
   16 nginx     0:00 nginx: worker process
   17 nginx     0:00 nginx: worker process
   18 nginx     0:00 nginx: worker process
   19 root      0:00 /bin/sh
   27 root      0:00 /bin/sh
   33 root      0:00 ps a

fsGroup to 82 also

That works, too, just as my fix with (0, 0, 82). What are you hoping to achieve with this?

Here's the ps a output if that's helpful:

/app # ps a
PID   USER     TIME  COMMAND
    1 root      0:00 {supervisord} /usr/bin/python3 /usr/bin/supervisord -c /etc/supervisor.d/supervisord.ini
    7 root      0:00 php-fpm: master process (/usr/local/etc/php-fpm.conf)
    8 root      0:00 nginx: master process /usr/sbin/nginx -g daemon off;
    9 www-data  0:00 php-fpm: pool www
   10 www-data  0:00 php-fpm: pool www
   11 nginx     0:00 nginx: worker process
   12 nginx     0:00 nginx: worker process
   13 nginx     0:00 nginx: worker process
   14 nginx     0:00 nginx: worker process
   15 nginx     0:00 nginx: worker process
   16 nginx     0:00 nginx: worker process
   17 nginx     0:00 nginx: worker process
   18 nginx     0:00 nginx: worker process
   19 root      0:00 /bin/sh
   27 root      0:00 /bin/sh
   33 root      0:00 ps a

To make the .env writable :D

Nope, same issue:

/app # ls -l .env 
-rw-r--r--    1 root     root           644 Jun 10 17:31 .env

Nope, same issue:

/app # ls -l .env 
-rw-r--r--    1 root     root           644 Jun 10 17:31 .env

Well, in that case and considering the .env is already present in the container. It might be better to open a bug upstream that they should chown the file in their Dockerfile.

Well, in that case and considering the .env is already present in the container. It might be better to open a bug upstream that they should chown the file in their Dockerfile.

I agree that this is an upstream issue, so I opened one:

Kovah/LinkAce#499

If I understand correctly this is a limitation of the first-time setup wizard which is probably more complicated to implement than your idea to modify our mirror image. I think the change is small enough, improves usability, and possible reduces the number of support tickets coming your way.

Now I remember why I was familiar with this .env file problems....
Kovah/LinkAce#398

This PR is locked to prevent necro-posting on closed PRs. Please create a issue or contact staff on discord if you want to further discuss this